1. Field of the Invention
This invention relates to computer memory systems, and more particularly to improvements in methods and apparatus for managing block oriented memory systems (as defined below), and still more particularly to improvements in methods and apparatuses for managing reference counts of block oriented memory systems employing reference counts in memory management.
2. Background Information
Reference counting is an important memory management technique for rapid reclamation of inaccessible memory. Efficient and cost-effective implementation of reference counting will alleviate the need for frequent garbage collection, which is an expensive operation. Reference counting has been known since about 1960. See, for example, Collins, G. E., "A method for overlapping erasure of lists," Communications of the ACM, Vol. 3, No. 12, 1960, pp. 655-657, and has undergone many refinements, see, for instance, Knuth, D., The Art of Computer Programming, Addison-Wesley, Reading, Mass., 1973, and Standish, T. A., Data Structure Techniques, Addison-Wesley, Reading, Mass., 1980.
The basic idea is to maintain a count of the number of pointers that reference each block of memory. If the reference count of a block should fall to zero, the block is no longer accessible, i.e., it is garbage, and its space can be reclaimed and reused. After a block becomes garbage, it is scanned to decrement reference counts of the referent blocks it references. Then the block is cleaned-up (i.e., initialized), and its space is made available for reuse. Examples of computer systems employing the reference counting technique are, the Xerox-Dorado Smalltalk-80 system described by Goldberg and Robson, "Smalltalk-80: The Language and its Implementation," Addison-Wesley, Reading, Mass., 1983, and LOOM, Kaehler and Krasner, LOOM-Large Object-Oriented Memory for Smalltalk-80 Systems, in Smalltalk-80: Bits of History, Words of Advice, Addison-Wesley, Reading, Mass., 1983, p. 249, and Stamos, "A large object-oriented virtual memory: Grouping strategies, measurements, and performance," Xerox Technical Report, SCG-82-2, Xerox Palo Alto Research Center, Palo Alto, CA, May 1982.
Reference counting provides a mechanism of rapid reclamation of memory space. It also provides the percentage utilization of memory, as well as, and portions of memory, such as each memory page. This information is very important in many applications; for example, it is used in certain garbage collection and compacting schemes, such as that disclosed in U.S. Patent application by T. McEntee et al. entitled "Method for Managing Virtual Memory to Separate Active and Stable Memory Blocks", Ser. No. 634,334, filed July 24, 1984, now allowed, said application being assigned to the assignee hereof, and incorporated herein by reference. Thus, not only is a reference counting scheme important for the memory compactor, reference counting also provides a cross-check for garbage collection, and is expected to help the design of robust memory management and aid in error recovery.
Reference is also made to U.S. patent application by Thatte et al., entitled "Computer System Enabling Automatic Memory Management Operations", Ser. No. 630,478, filed July 12, 1984, pending. This application is assigned to the assignee hereof, and is incorporated herein by reference. This application discloses a computer system having an associated memory which has a memory management unit (MMU) to perform the memory management functions. In the MMU, there are two sources of references for memory blocks; the first one is binding registers (to which the memory blocks may be bound, as disclosed in said applications) and the second one is memory cells of other or the same block. The reference count of a block in these systems is therefore the sum of the number of pointers originating at binding registers and the number of pointers originating at memory cells.
Thus, for example, with reference to FIG. 1, an example of the reference count structure of the Thatte et al. application is shown. As shown, a number of binding registers 10 associated with a CPU 12 reference blocks in an associated memory. In the case shown, blocks 14 and 16 are referenced. Additionally, the blocks of memory may reference themselves or other blocks. Thus as shown, block 14 references both block 15 and block 16, and block 15 refers to itself. Also, one of the binding registers 10 refers to block 14, and two of the binding registers 10 refer to the block 16. The reference counts of each of the blocks, therefore, can be seen to be, block 14=1; block 15=2; and block 16=3.
The reference count of a block can change as a result of writing new data in a binding register or a memory cell. The new data may destroy an existing pointer in a binding register or a memory cell, which will result in a decrease of the reference count of the referent block by one; moreover, the new data may itself be a pointer, which when written will result in an increase of the reference count of the referent block by one.
Reference counting does have certain disadvantages which should be considered. In general, reference count operations cannot reclaim garbage blocks in a circular pointer structure; hence, garbage collection is necessary. This is an intrinsic and unavoidable problem with reference counting, and is not addressed by the invention herein. Additionally, counting references takes time. For each instruction that writes new data in a binding register or in a memory cell, the existing contents of the binding register or the memory cell must first be read to determine whether a pointer will be destroyed, as a result of writing new data. In the machine of the above mentioned application, Ser. No. 630,478, if the MMU tag of the existing contents indicates a pointer, then obviously a pointer will be destroyed. If an existing pointer is destroyed, then the header of the referent block must be read to retrieve the reference count, the reference count is decremented by one, and finally the updated reference count is stored back in the header of the referent block. Thus, for example, in FIG. 2, when data is written into a cell of a block 20 which previously contained a pointer, the pointer will be destroyed. The reference count of the referent block 21 (also referred to by a pointer of a block 22) will be decremented from "2" to "1", since now only block 22 refers to it.
Similarly the new data being written must also be checked to see if it is a pointer. In the machine of the aforementioned patent application Ser. No. 630,478 this is determined by inspecting the MMU tag of new data. If the data is a pointer, then a new pointer will be created, which requires that the header of the referent block must be read to retrieve the reference count, the reference count is incremented by one, and finally the updated reference count is stored back in the header of the referent block. This is illustrated in FIG. 3 in which a new pointer is written into a cell of a block 30 which thereafter points to block 31. Block 31 previously was referenced only by block 32, and its reference count was "1". After the new pointer is written into block 30, the reference count will need to be incremented to be "2".
As described above, the reference management is a time consuming operation. Unger quotes private communication with Deutsch, as cited in Unger, D., "Generational scavanging: A nondisruptive high performance storage reclamation algorithm," Proceedings of the ACM SIGSOFT/SIGPLAN Software Development Environments, Pittsburgh, PA, April, 1984, pp. 157-167, and his own work set forth in Unger and Patterson, "Berkeley Smalltalk: Who knows where the time goes?", in Smalltalk-80: Bits of History, Word of Advice, Addison-Wesley, Reading, Mass., 1983, p. 189, to report that reference count management consumes 15 percent of CPU time, assuming that the CPU is responsible for reference count management. When the reference count of a block reaches zero, it must be scanned to decrement the reference counts of all referent blocks it references. This recursive freeing consumes an additional 5 percent of CPU time, according to Deutsch, L. P., Storage reclamation, Berkeley Smalltalk seminar, Feb. 5, 1982, and Unger and Patterson, supra. Thus, the total overhead of reference counting is about 20 percent of CPU time, assuming that the CPU is responsible for reference count management. This is an unacceptable overhead as fully one-fifth of the CPU time is "wasted" in reference count management. In the absence of efficient techniques to implement reference counting, not many machines have embraced the technique in practice, though the literature abounds with reference counting schemes and their uses.
Reference counting is a memory management function, and hence, in the machines of the aforementioned patent application, Ser. No. 630,478 is implemented by the MMU. Therefore, the overhead experienced by the CPU for reference count management is reduced; however, the CPU is not completely relieved from the reference counting overhead, as presently described.
For each instruction that writes new data in a binding register, the CPU needs to check if an existing pointer is being destroyed or a new pointer is being created, and then notify the MMU accordingly so that the MMU can update the reference count appropriately. The CPU must read the existing contents of a binding register before it can be written with new data, and must dispatch on the MMU tag of the existing contents to determine whether it is a pointer. Similarly, it must also dispatch on the MMU tag of the new data to determine whether a new pointer will be created.
When an existing pointer in a binding register is destroyed, the CPU needs to send a "(Destroyed-pointer Virtual-address)" notification to the MMU so that the MMU can decrement the reference count of the referent block residing at the virtual address, specified by the Destroyed-pointer command. Similarly, when a new pointer in a binding register is created, the CPU needs to send a "(Created-pointer Virtual-address)" notification to the MMU so that the MMU can increment the reference count of the referent block residing at the virtual address. All these operations make a simple WRITE instruction on a binding register very time consuming (4 to 6 cycles), complicate the CPU microcode design, and adversely affect the performance.
"Destroyed-pointer" and "Created-pointer" notifications result into interruptions of the current task of the MMU, and hog the bandwidth of the CPU-MMU interface, degrading performance. As will become apparent, the purpose of the invention is to reduce the CPU overhead for reference count management as much as possible.
It has been recognized that the CPU overhead of detecting the creation and destruction of pointers in binding registers, and then notifying the MMU about these events, can be reduced, by not counting references originating from binding registers in the reference counts. By not counting the binding register references, the reference count of a block indicates only the number of pointers originating at memory cells.
Another beneficial consequence of not counting binding register references is that a large share of reference count activity of incrementing and decrementing reference counts arising from creation and destruction of pointers in binding registers is reduced. It has also been recognized that the manner by which the reference counts of the binding registers are maintained must be carefully implemented. For instance, when the reference count of a block drops to zero, the MMU must inquire of the CPU whether any binding register is still holding a pointer to the block by sending the virtual address of the block to the CPU. The CPU must respond to this querry interruption by interrogating each of its binding registers, and indicate to the MMU whether or not any binding register is holding the virtual address sent by the querry. This interrogation is a time consuming sequential operation unless supported by very expensive parallel associative-search hardware.
If the outcome of the interrogation is negative, i.e., no binding register holds the pointer, then the MMU knows that the block is garbage and it reclaims it and makes it ready for reuse. On the other hand, if the interrogation indicates that there is a binding register holding the pointer, then obviously the block is not garbage. At some later time, the MMU, therefore, must resubmit the querry to the CPU to find out whether any binding registers still hold the pointer to the block. These frequent querry operations to the CPU result in a performance degradation.
Thus, this "solution" of frequently interrupting the CPU is querry whether any binding register is holding a pointer to a block whose reference count has dropped to zero is undesirable.